Network Working Group S. Allen 


Request for Comments: 4047 UCO/Lick Observatory 
Category: Informational D. Wells 
National Radio Astronomy Observatory 

April 2005 


MIME Sub-type Registrations for 
Flexible Image Transport System (FITS) 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 
Abstract 


This document describes the registration of the Multipurpose Internet 
Mail Extensions (MIME) sub-types to be used by the international 
astronomical community for the interchange of Flexible Image 
Transport System (FITS) files. The encoding is defined by the 
published FITS standard documents. The FITS format has been in use 
since 1979, and almost all data from astronomical observations are 
interchanged by using FITS. 
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1. Introduction 


The FITS file format [FITS] was designed in order to facilitate the 
interchange of astronomical image data between observatories. FITS 
provides a means of transporting arrays and tables of data and 
keyword/value pairs of metadata. FITS is defined by standards 
documents that are approved by the International Astronomical Union 
(IAU, http://www.iau.org/) and published in refereed journals. 


Before the inception of HTTP, astronomers used the Internet to 
exchange FITS files. Multiple unofficial media types for FITS files 
[ASU] came into use shortly after the inception of the WWW and have 
remained in use. Currently (2005) the international astronomical 
community is pursuing many cooperative efforts (e.g., [IVOA], [NVO], 
[AstroGrid], [AVO]) to produce web services that provide astronomical 
data. The exchange of FITS files is a fundamental element of the 
prototypes for these web services [SIAP]. The astronomical community 
has to agree to use one set of media types for FITS files in order to 
promote interoperability of its various services. 


In its simplest form, FITS is used as a means of transporting 
astronomical image data in a raster form along with coordinate 
information and other standard and locally defined metadata. In such 
applications FITS is much like the well-known TIFF format [TIFF] with 
the addition of the GeoTIFF tags [GeoTIFF]. However, FITS is capable 
of describing a much broader range of data than 2-dimensional 
rasters. A consensus has developed in the FITS community that two 
media types are needed: one for images and one for all other cases. 


2. Conventions Used in this Document 
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [Require]. 


3. Overview 


This document describes the registration of the MIME media sub-types 
"application/fits" and "image/fits". 
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In 1988 the International Astronomical Union formed the FITS Working 
Group (IAUFWG) to oversee matters pertaining to the evolution of the 
FITS data format. The IAUFWG has approved the submission of this 
document and the registration of these two MIME types. 


4. FITS Definition 


FITS is defined by a document approved by the International 
Astronomical Union (IAU) and published in the journal Astronomy & 
Astrophysics [NOST]. Conventions for additional keywords used in 
FITS files are proposed by interested parties and negotiated and 
reviewed by ad hoc committees of the FITS community. If such usage 
of additional keywords is approved by national committees and the 
IAUFWG then they become new reserved keywords in the FITS standard 
and are published in an ongoing series of papers (e.g., [WCS1, 
WCS2]). 


Copies of the standard documents can be found at the following sites: 
http://fits.gsfc.nasa.gov/ 

http://archive.stsci.edu/fits/ 

http://www.cv.nrao.edu/fits/ 
http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html 

Although a brief structure and feature description is provided in 
this section as background information, the reader is directed to the 
FITS standards documents to obtain complete feature and technical 
details. 


4.1. FITS Structure 


A FITS file consists of a sequence of one or more header and data 


units (HDUs) optionally followed by special records. The structure 
of a FITS file is based on blocks with a length of 2880 8-bit bytes 
(23040 bits). This size was chosen because it is evenly divisible by 


the byte and word lengths of all known computer systems. All FITS 
files have lengths that are integral multiples of this block size. 


Each FITS header consists of a sequence of one or more 2880-byte 
blocks that hold 36 80-character records (36*80=2880). The records 
consist of ASCII keyword/value pairs plus optional comments. The 
character set is the 7-bit printing ASCII codes, including the ASCII 
space. In particular, the control codes CR, LF, FF, TAB and NUL are 
not used in FITS headers. The keywords are up to 8 characters in 
length. Some keywords are mandatory, and their meaning is rigidly 
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prescribed. Among these are keywords that describe the structure and 
size of the subsequent data array. The standard reserves other 
keywords for the purpose of conveying specifically defined items of 
metadata. Keywords that are neither mandatory nor reserved may be 
inserted with semantics that are defined by local conventions. (Some 
local conventions have later been adopted into standardized 
practice.) The end of the header is signified by a block containing 
the keyword "END". A simple example of a FITS header for a digital 
image, using only keywords that were specified in the initial FITS 
Agreement of March 1979 [FITS], is as follows: 


al 2 3 4 5 6 
1234567890123456789012345678901234567890123456789012345678901234567.. 


SIMPLE = T / file does conform to FITS standard 
BITPIX = 16 / 16-bit twos-complement pixel values 
NAXIS = 2 / 2-dimensional image 

NAXIS1 = 512 / first axis length 

NAXIS2 = 512 / second axis length 

COMMENT ----------------------------------------------------- 


COMMENT FITS (Flexible Image Transport System) format is defined 
COMMENT in Astronomy and Astrophysics’, volume 376, page 359; 
COMMENT bibcode: 2001A&A...376..359H 


COMMENT ----------------------------------------------------- 
ORIGIN = ’Lick Observatory pe af; 

DATE = '2003-11-22T05:23:45’ / when this file was written 
END 


(These 13 records are followed by 23 80-character records of ASCII 
spaces, to pad the header block to the 2880-byte FITS block size.) 


The first keyword/value pair, SIMPLE=T, is the signature of FITS; all 
FITS files begin with these characters. BITPIX is the second keyword 
of all FITS files; legal values for it are 8, 16, 32, -32 and -64. 
NAXIS is the third keyword of all FITS files; legal values for it are 
0 to 999. NAXIS=0 is legal, and implies that there is no image data 
matrix associated with the header (and the NAXISi keywords must not 
be present); this value is common for files that will be given the 
media type "application/fits" as discussed in section 5.1 of this 
document. NAXIS=2 is the value most often used for files that will 
be given the media type "image/fits", as discussed in section 5.2 of 
this document (NAXIS=3 FITS images are also common). The COMMENT 
records will be ignored by FITS reading software, but are used here 
to specify the precise journal citation for the FITS standard, an 
item of information that is important for archiving on timescales of 
decades. The ORIGIN keyword is commonly used in FITS files to encode 
the name of the institution where the file was produced. The DATE 
keyword is used to convey the timestamp for the file (whereas the 
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keyword DATE-OBS is used to convey observation start times). FITS 
headers commonly contain a vast variety of additional keywords used 
to encode metadata. In particular, a digital image header will often 
include keywords to specify the precise celestial coordinates of the 
pixels of the 2-D matrix, with conventions that became part of the 
FITS standard in 2002 (see [WCS2]). Finally, the above example 
demonstrates how, in addition to the COMMENT records, 60% of the 
bytes in keyword=value records in FITS headers are reserved for 
comments. Although the simple header example above is contained in 
only one FITS block, multi-block FITS headers are commonly 
interchanged. 


Following each header is a data unit that consists of a sequence of 
zero or more 2880-byte blocks. In accordance with the description in 
the keywords of their header, these blocks contain an N-dimensional 
data array, optionally followed by other small groups of array data. 
In most cases, the data array represents either an N-dimensional 
array of image pixel values or a 2-dimensional array of tabular data. 


Following the HDUs a FITS file may contain zero or more 2880-byte 
blocks of special records. The standard does not specify anything 
about their content. (This convention for special records is not 
known to have been used for any purpose other than prototyping new 
elements of the standard, such as random groups and BINTABLE.) 


The initial HDU in a FITS file is known as the primary HDU (PHDU); 
any subsequent HDU is known as an extension HDU (XHDU). The keyword 
content of the PHDU is distinct (a PHDU requires a slight alteration 
before it can become an XHDU, and most types of XHDU cannot become a 
PHDU). A PHDU may have a data array consisting of zero elements, and 
this will often be the case for FITS files intended to communicate 
tables and multiple images. An XHDU may be one of several standard 
types, or it may be another conforming type. Standard types of XHDU 
include "IMAGE" (containing an N-dimensional data array similar in 
most respects to the PHDU), "TABLE" (containing a 2-dimensional table 
of ASCII character data), and "BINTABLE" (containing a 2-dimensional 
table of binary data whose elements may themselves be multi- 
dimensional arrays). 


4.2. History of FITS Features 


In 1981 the original definition of FITS described a single HDU 
containing one multi-dimensional image array [FITS], as illustrated 
by the sample header shown in section 4.1. Subsequent agreements 
have used the original framework of HDUs and keyword/value pairs to 
extend FITS while preserving the validity of all existing files. 
FITS now has standard means of describing multiple arrays of image 
data and/or multiple tables of numeric and character information. 
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Brief highlights of the history of FITS 


1979: Initial FITS Agreement and first interchange of files 


1980: Random groups convention developed 

- 1981: Published original (single HDU) definition [FITS] 
- 1981: Published random groups definition [GROUPS] 

- 1982: Formally endorsed by the IAU 

—- 1988: Defined rules for multiple HDUs [XTENSION] 

-— 1988: FITS Working Group established by IAU [IAUFWG] 
- 1988: Extended to include ASCII tables [TABLE] 

- 1990: Extended to include IEEE floating-point data 
- 1994: Extended to multiple image arrays [IMAGE] 

- 1995: Extended to binary tables [BINTABLE] 

- 1997: Adopted a Y2K-compliant date format 


- 2001: Reiterated existing standard in one paper [NOST] 


2002: Approved conventions for world coordinates [WCS1, WCS2] 
4.3. Stability of the FITS Definition 


After the adoption of FITS by the IAU in 1982, some in the emerging 
community of FITS users realized that there would be tension between 
the need for archival stability and the need for evolution. In order 
to satisfy both of these requirements they set up a controlled 
parliamentary process. At the time of the Generalized Extensions 
Agreement [XTENSION], the meta-agreement that controls the evolution 
of FITS, the FITS community adopted the guiding principle "Once FITS, 


always FITS". Under this rule, no change may be made to FITS that 
invalidates existing files. Changes to the FITS standard occur only 
after action by the IAU FITS Working Group (FWG). The FWG acts only 


after approval by regional working groups that coordinate FITS 
activity in various parts of the world. 


FITS has been adopted as the archival format for image data and 


interferometric data obtained by many ground-based observatories and 
for all data from many spacecraft. Many astrophysical archives store 
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their data in FITS format, and most astronomical catalog data has 
been transcribed into FITS files. The many terabytes of data in 
these archives contribute to the stability of the FITS standard. 


4.4. Portability of FITS files 


Eric Greisen, one of the authors of the original document [FITS], 
relates that in 1979 


[tlhe first FITS files were written by a PL/I program on an IBM 
360 under OS/MFT (32-bit, twos-complement numbers and 8-bit EBCDIC 
characters) and were read by a Fortran program executing on a CDC 
6400 under SCOPE (60-bit, ones-complement numbers and 6-bit 
"Display Code" characters). [Remark] 


Subsequent evolution of computing hardware and FITS over 25 years has 
not degraded this ability to transfer the data content. 


The structure of FITS files is extremely general, and this 
necessarily complements the nature of astronomical data. FITS is 
used to store observations of the entire electromagnetic spectrum 
from radio to gamma rays, from ground-based observatories and from 
spacecraft. FITS is also used to communicate physical properties 
other than radiation intensity; these may be inferred from 
observations or calculated by theoretical models. The pedigree of 
data in a FITS file typically varies among disciplines; FITS may be 
used to store raw and uncalibrated data, completely reduced and 
calibrated data, or both. Nevertheless, the FITS standard provides 
that the syntactic content of the data and metadata are unambiguously 
available to posterity. 


Observatories have developed numerous local conventions for the 
storage and transfer of data peculiar to their instrumentation and 
purview. Application software for handling FITS files from different 
regions of the electromagnetic spectrum has been largely disjoint. 
For a FITS file that consists of multiple HDUs there are no widely 
established conventions governing the meaning of, interrelations 
between, and suggested use of the data sets. Recognition of any 
local conventions used for FITS data has often been based on 
heuristics of the additional (non-standard) keyword/value pairs. 
Fully understanding the semantic content of a FITS file usually 
requires an external data dictionary. 


4.5. Application Programming Interfaces to FITS 
Although the definition of FITS is expressed in terms of the bit 


content of the files, there are widely supported application 
programming interfaces (APIs) which simplify the task of manipulating 
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FITS files. Interfaces exist for many languages and operating 
systems. A partial list of APIs follows: 


CFITSIO http://heasarc.gsfc.nasa.gov/fitsio/ 

fitsTcl http://heasarc.gsfc.nasa.gov/ftools/fv/fitsTcl_home.html 
WCSLIB http://www.atnf.csiro.au/people/mcalabre/WCS/ 

PyFITS http://www.stsci.edu/resources/software_hardware/pyfits 
WCSTools http://tdc-www.harvard.edu/software/wcstools/ 

FUNTOOLS http://hea-www.harvard.edu/RD/funtools/ 

IDLASTRO http://idlastro.gsfc.nasa.gov/ 

fitsy http://cfa-www.harvard.edu/~ john/fitsy/ 

IUEDAC http://archive.stsci.edu/iue/iuedacfits.html 


Mathematica http://documents.wolfram.com/v5/Built-—inFunctions/ 
GraphicsAndSound/ImportAndExport/ 
AdditionaliInformation/Import.html 

MatLab http://www.mathworks.com/access/helpdesk/help/techdoc/ 
ref/fitsread.shtml?cmdname=fitsread 


Current lists of more APIs can be found at 
http://fits.gsfc.nasa.gov/fits_libraries.html 


List of applications that use FITS are found in the IANA 
registrations of the media types. 


4.6. FITS File Conformance Testing 


FITS files can be tested for conformance to the Definition of FITS 
rules [NOST, WCS1, WCS2] with an application named "fitsverify", 
which is available at 


http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ 


in the form of executable binary files for Solaris, Linux, and 
Windows platforms, as well as in source code. Although "fitsverify" 
has not been endorsed by the IAUFWG, users should be aware that the 
designer of the program was the Secretary of the Technical Panel that 
produced the published FITS standard [NOST]. 


4.7. Archives That Distribute FITS Files 


As noted in section 4.3 of this RFC, massive (multi-terabyte) data 
archives that contain and/or distribute FITS files contribute to the 
stability of the FITS standard. There are numerous publicly 
available archives of FITS files derived from both space and ground- 
based observations that span the entire range of the electromagnetic 
spectrum from radio to gamma-ray wavelengths. The following are 
examples of such archives, in no particular order: 
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for archive access 


KPNO,CTIO,.. http://archive.noao.edu/nsa/ 

VLT,HST,.. http://archive.eso.org/ 

Subaru http://smoka.nao.ac.jp/ 

SDSS http://www.sdss.org/dr3/ 

CFHT http://cadcwww.dao.nre.ca/cfht/cfht html 

VLA, VLBA, GBT http://e2e.aoc.nrao.edu/archive/archive_describe.html 

HST, MAST http://archive.stsci.edu/ 

HEASARC http://heasarc.gsfc.nasa.gov/w3browse/ 

Chandra http://cxc.harvard.edu/cda/ 

LaPalma http://archive.ast.cam.ac.uk/ingarch/ 

BIMA http://bimaarch.ncsa.uiuc.edu/ 

Keck-DEIMOS http://archive.deep.ucolick.org/ 

Compt onGRO http://cossc.gsfc.nasa.gov/archive/index.html 

Spitzer,.. http://www.ipac.caltech.edu/ 

AAT http://www.aao.gov.au/archive/ 

HIPASS http://www.atnf.csiro.au/research/multibeam/ 
multibeam. html 

JCMT http://salish.dao.nrce.ca:8080/jcmt/intro.html 

COBE, WMAP http://lambda.gsfc.nasa.gov/ 

EVN http://www. jive.nl/archive/scripts/listarch.php 

Gemini http://gemini.ast.cam.ac.uk/sciops/data/dataIndex.html 

XMM-Newton http://xmm.vilspa.esa.es/external/xmm_data_acc/xsa/ 


5. IANA Considerations 


The general nature of the full FITS standard requires the use of the 
media type "“application/fits". Nevertheless, the principal intent 
for a great many FITS files is to convey a single data array in the 
PHDU, and such arrays are very often 2-dimensional images. Several 
common image viewing applications already display single-HDU FITS 
files, and the prototypes for virtual observatory projects specify 
that data provided by web services be conveyed by the data array in 
the PHDU. These uses justify the registration of a second media 
type, namely "image/fits", for files which use the subset of the 
standard described by the original FITS standard paper [FITS]. 


We note that the media type "image/gif" [MIME2] admits raster images 
that are three dimensional, because animated GIF images contain two 
spatial dimensions and one temporal dimension. We note that the 
media types "image/vnd.dwg" and "image/vnd.dxf" admit data that 
include three-dimensional vectors and curves as well as objects 
created by using constructive solid geometry. Following these 
precedents for the "image" media type, we specify that "image/fits" 
MAY be used to describe FITS PHDUs that have other than two 


dimensions. We expect that most files described as "image/fits" will 
have two-dimensional (NAXIS=2) PHDUs. 
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5.1. Registration of application/fits 


To: ietf-types@iana.org 
Subject: Registration of Standard MIME Media type application/fits 


MIME media type name: application 

MIME subtype name: fits 

Required parameters: none 

Optional parameters: none 

Encoding considerations: binary 

FITS files can be quite large. When transferred via HTTP it may be 
efficient for the transaction to make use of content-coding or 
transfer-coding values such as "gzip", "compress", or "deflate". 
Security considerations: 

FITS provides a means of transporting arrays and tables of data and 
keyword/value pairs of metadata. The standard FITS keywords are 
either mandatory or reserved. Mandatory keywords provide information 
necessary for correct interpretation of the data; reserved keywords 
merely provide standard bits of metadata. As such, the current 
standard FITS keywords do not pose security risks. 

A FITS file author may insert additional keywords with semantics that 


are not described by the standard. Parties exchanging FITS files may 
employ locally defined conventions that use various keywords and 


their values to induce actions on the part of the recipient. There 
are existing local conventions where such keywords are used to 
request the reading of other files and/or URIs. There are other 
local conventions where such keywords are used to modify the state of 
a telescope and/or instrument. The security implications of local 
conventions such as these SHOULD be analyzed by the parties employing 
them. 


Interoperability considerations: 


FITS files have been successfully transported between wildly 
different computers since 1979. The difficulty most likely to be 
encountered by a FITS application is inability to acquire the 
computational resources required by a very large FITS file. 
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Published specification: 


The specification for this content type is published as a series of 
papers in refereed astronomical journals: 


Hanisch, R., et al., "Definition of the Flexible Image Transport 
System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001. 


Greisen, E. and M. Calabretta, "Representations of world coordinates 
in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002. 


Calabretta, M. and E. Greisen, "Representations of celestial 
coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002. 


Copies of these specifications can also be found via: 
http://fits.gsfc.nasa.gov/ 
http://archive.stsci.edu/fits/ 
http://www.cv.nrao.edu/fits/ 
http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html 
Applications that use this media type: 


There are many astronomical image viewing and data reduction 
applications including, but not limited to, the following list: 


IRAF http://iraf.noao.edu/ 

AIPS http://www.aoc.nrao.edu/aips/ 

AIPS++ http://aips2.nrao.edu/ 

MIDAS http://www.eso.org/projects/esomidas/ 
ds9 http: //hea-www.harvard.edu/RD/ds9/ 

fv http://heasarc.gsfc.nasa.gov/ftools/fv/ 


Aladin http://aladin.u-strasbg.fr/ 
Starlink http://star-www.rl.ac.uk/ 
Miriad http://bima.astro.umd.edu/miriad/ 


STSDAS http://www.stsci.edu/resources/software_hardware/stsdas 
PROS http: //hea-www.harvard.edu/PROS/pros.html 

CIAO http://cxc.harvard.edu/ciao/ 

XANADU http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html 
HESSI http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/ 


FITSview http://www.nrao.edu/software/fitsview/ 
XMM-SAS http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml 


At the present time many of these applications are not designed to 


support use as viewers of "application/fits" files in association 
with web browsers. 
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Additional information: 


A FITS file described with the media type "application/fits" SHOULD 
conform to the published standards for FITS files as determined by 
convention and agreement within the international FITS community. No 
other constraints are placed on the content of a file described as 
"application/fits". 


A FITS file described with the media type "application/fits" may have 
an arbitrary number of conforming extension header and data units 
(XHDUs) that follow its mandatory primary header and data unit 
(PHDU). The XHDUs may be one of the standard types ("IMAGE", 
"TABLE", and "BINTABLE") or any other type that satisfies the 
"Requirements for Conforming Extensions" (section 4.4.1 of [NOST]). 
The PHDU or any "IMAGE" XHDU may contain zero to 999 dimensions with 
zero or more pixels along each dimension. 


The PHDU may use the random groups convention, in which the dimension 
of the first axis is zero and the keywords GROUPS, PCOUNT and GCOUNT 
appear in the header. NAXIS1=0 and GROUPS=T is the signature of 
random groups; see section 7 of the Definition of FITS paper [NOST]. 


Recommendations for application writers: 


An application intended to handle "application/fits" SHOULD be able 
to provide a user with a manifest of all of the HDUs that are present 
in the file and with all of the keyword/value pairs from each of the 
HDUs. 


An application intended to handle "application/fits" SHOULD be 
prepared to encounter XHDUs that contain either ASCII or binary 
tables, and to provide a user with access to their elements. 


An application which can modify FITS files or retrieve FITS files 
from an external service SHOULD be capable of writing such files toa 
local storage medium. 


Complete interpretation of the meaning and intended use of the data 
in each of the HDUs typically requires the use of heuristics that 
attempt to ascertain which local conventions were used by the author 
of the FITS file. 


As examples, files with media type "application/fits" might contain 
any of the following contents: 


- An empty PHDU (containing zero data elements) followed by a table 
HDU that contains a catalog of celestial objects. 
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- An empty PHDU followed by a table HDU that encodes a series of 
time-tagged photon events from an exposure using an X-ray detector. 


- An empty PHDU followed by a series of IMAGE HDUs containing data 
from an exposure taken by a mosaic of CCD detectors. 


- An empty PHDU followed by a series of table HDUs that contain a 
snapshot of the state of a relational database. 


- A PHDU containing a single image along with keyword/value pairs of 
metadata. 


- A PHDU with NAXIS1=0 and GROUPS=T followed by random groups data 
records of complex fringe visibilities 


Magic number(s): "SIMPLE = T 


Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has 
contributed database entries for the magic number file which is used 
by the Unix "file" command. Magic number files with these entries 
are distributed with a variety of Unix-like operating systems. In 
addition to recognizing a FITS file using the string given above, the 
Uphoff entries also recognize the data type of the pixels in the 
PHDU. 


File extension (s): fits 


This file extension SHOULD NOT be interpreted as a prescription. 


The FITS standard originated in the era when files were stored and 
exchanged via magnetic tape; it does not prescribe any nomenclature 
for files on disk. Various sites within the FITS community have 
long-established practices where files are presumed to be FITS by 
context. File extensions used at such sites commonly indicate 
content of the file instead of the data format. 


In the absence of other information it is reasonably safe to presume 
that a file name ending in ".fits" is intended to be a FITS file. 
Nevertheless, there are other commonly used extensions; e.g., ".fit", 
"fts", and many others not suitable for listing in a media type 
registration. 

Intended usage: Common 


Persons to contact for further information: 


"Steve Allen" <sla@ucolick.org> 
"Don Wells" <dwells@nrao.edu> 
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Author/Change controller: 
"Steve Allen" <sla@ucolick.org> 
The IAU FITS Working Group may authorize changes to this document. 
5.2. Registration of image/fits 


To: ietf-types@iana.org 
Subject: Registration of Standard MIME Media type image/fits 


MIME media type name: image 

MIME subtype name: fits 

Required parameters: none 

Optional parameters: none 

Encoding considerations: binary 

FITS files can be quite large. When transferred via HTTP it may be 
efficient for the transaction to make use of content-coding or 
transfer-coding values such as "gzip", "compress", or "deflate". 
Security considerations: 

FITS provides a means of transporting arrays and tables of data and 
keyword/value pairs of metadata. The standard FITS keywords are 
either mandatory or reserved. Mandatory keywords provide information 
necessary for correct interpretation of the data; reserved keywords 
merely provide standard bits of metadata. As such, the current 
standard FITS keywords do not pose security risks. 

A FITS file author may insert additional keywords with semantics that 


are not described by the standard. Parties exchanging FITS files may 
employ locally defined conventions that use various keywords and 


their values to induce actions on the part of the recipient. There 
are existing local conventions where such keywords are used to 
request the reading of other files and/or URIs. There are other 
local conventions where such keywords are used to modify the state of 
a telescope and/or instrument. The security implications of local 
conventions such as these SHOULD be analyzed by the parties employing 
them. 
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Interoperability considerations: 


FITS files have been successfully transported between wildly 
different computers since 1979. The difficulty most likely to be 
encountered by a FITS application is inability to acquire the 
computational resources required by a very large FITS file. 


Published specification: 


The specification for this content type is published as a series of 
papers in refereed astronomical journals: 


Hanisch, R., et al., "Definition of the Flexible Image Transport 
System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001. 


Greisen, E. and M. Calabretta, "Representations of world 
coordinates in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002. 


Calabretta, M. and E. Greisen, "Representations of celestial 
coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002. 


Copies of these specifications can also be found via: 
http://fits.gsfc.nasa.gov/ 
http://archive.stsci.edu/fits/ 
http://www.cv.nrao.edu/fits/ 
http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html 
Applications that use this media type: 


There are many astronomical image viewing and data reduction 
applications including, but not limited to, the following list: 


IRAF http://iraf.noao.edu/ 

AIPS http://www.aoc.nrao.edu/aips/ 

AIPS++ http://aips2.nrao.edu/ 

MIDAS http://www.eso.org/projects/esomidas/ 
ds9 http://hea-www.harvard.edu/RD/ds9/ 

fv http://heasarc.gsfc.nasa.gov/ftools/fv/ 


Aladin http://aladin.u-strasbg.fr/ 
Starlink http://star-www.rl.ac.uk/ 
Miriad http://bima.astro.umd.edu/miriad/ 


STSDAS http://www.stsci.edu/resources/software_hardware/stsdas 
PROS http: //hea-www.harvard.edu/PROS/pros.html 
CIAO http://cxc.harvard.edu/ciao/ 


XANADU http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu. html 
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HESSI http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/ 
FITSview http://www.nrao.edu/software/fitsview/ 
XMM-SAS http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml 


Non-astronomical FITS image display applications include: 


netpbm http://netpbm. sourceforge.net/ 
gimp http://www.gimp.org/ 

IDL http://www.rsinc.com/ 
ImageMagick http://www. imagemagick.com/ 
Mathematica http://www.wolfram.com/ 

MatLab http://www.mathworks.com/ 

XV http://www.trilon.com/xv/xv.html 


There are also two FITS plug-ins for Adobe Photoshop 
(http: //www.adobe.com/products/photoshop/), available at 
http://astroshed.com/fitsplug/fitsplug.htm and 
http://www.spacetelescope.org/projects/fits_liberator/ 


At the present time many of the applications listed above are not 
designed to support use as viewers of "image/fits" files in 
association with web browsers. 


Additional information: 


A FITS file described with the media type "image/fits" SHOULD have a 
PHDU with positive integer values for the NAXIS and NAXISn keywords, 
and hence SHOULD contain at least one pixel. Files with 4 or more 
non-degenerate axes (NAXISn>1) SHOULD be described as 
"application/fits", not as "image/fits". (In rare cases it may be 
appropriate to describe a NULL image -- a dataless container for FITS 
keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+ non- 
degenerate axes as "image/fits" but this usage is discouraged because 
such files may confuse simple image viewer applications.) 


FITS files declared as "image/fits" MAY also have one or more 
conforming XHDUs following their PHDUs. These extension HDUs MAY 
contain standard, non-linear, world coordinate system (WCS) 
information in the form of tables or images. The extension HDUs MAY 
also contain other, non-standard metadata pertaining to the image in 
the PHDU in the forms of keywords and tables. 


A FITS file described with the media type "image/fits" SHOULD be 
principally intended to communicate the single data array in the 
PHDU. This means that "image/fits" SHOULD NOT be applied to FITS 
files containing MEF (multi-exposure-frame) mosaic images. Also, 
random groups files MUST be described as "application/fits" and not 
as “image/fits". 
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A FITS file described with the media type "image/fits" is also valid 
as a file of media type "application/fits". The choice of 
classification depends on the context and intended usage. 


Recommendations for application writers: 


An application that is intended to handle "image/fits" SHOULD be able 
to provide a user with a manifest of all of the HDUs that are present 
in the file and with all of the keyword/value pairs from each of the 
HDUs. An application writer MAY choose to ignore HDUs beyond the 
PHDU, but even in this case the application SHOULD be able to present 
the user with the keyword/value pairs from the PHDU. 


Note that an application intended to render "“image/fits" for viewing 
by a user has significantly more responsibility than an application 
intended to handle, e.g., "image/tiff" or "image/gif". FITS data 
arrays contain elements which typically represent the values of a 
physical quantity at some coordinate location. Consequently they 
need not contain any pixel rendering information in the form of 
transfer functions, and there is no mechanism for color look-up 
tables. An application SHOULD provide this functionality, either 
statically using a more or less sophisticated algorithm, or 
interactively allowing a user various degrees of choice. 


Furthermore, the elements ina FITS data array may be integers or 
floating-point numbers. The dynamic range of the data array values 
may exceed that of the display medium and the eye, and their 
distribution may be highly nonuniform. Logarithmic, square-root, and 
quadratic transfer functions along with histogram equalization 
techniques have proved helpful for rendering FITS data arrays. Some 
elements of the array may have values which indicate that their data 
are undefined or invalid; these should be rendered distinctly. Via 
WCS Paper I [WCS1] the standard permits "CTYPEnnn = ’COMPLEX’" to 
assert that a data array contains complex numbers (future revisions 
might admit other elements such as quaternions or general tensors). 


Three-dimensional data arrays (NAXIS=3 with NAXIS1, NAXIS2 and NAXIS3 
> 1) are of special interest. Applications intended to handle 
"image/fits" MAY default to displaying the first 2D plane of such an 
image cube, or they MAY default to presenting such an image in a 
fashion akin to that used for an animated GIF, or they MAY present 
the data cube as a mosaic of "thumbnail" images. Even in the absence 
of WCS indication of a temporal axis the time-lapse movie-looping 
display technique can be effective, and application writers SHOULD 
consider offering it for all three-dimensional arrays. 


An "“image/fits" PHDU with NAXIS=1 is describing a one-dimensional 
entity such as a spectrum or a time series. Applications intended to 
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handle "image/fits" MAY default to displaying such an image as a 
graphical plot rather than as a two-dimensional picture with a single 
row. 


An application that cannot handle an image with dimensionality other 
than 2 SHOULD gracefully indicate its limitations to its users when 
it encounters NAXIS=1 or NAXIS=3 cases, while still providing access 
to the keyword/value pairs. 


FITS files with degenerate axes (i.e., one or more NAXISn=1) MAY be 
described as "image/fits", but the first axes SHOULD be non- 
degenerate (i.e., the degenerate axes SHOULD be the highest 
dimensions). An algorithm designed to render only two-dimensional 
images will be capable of displaying such an NAXIS=3 or NAXIS=4 FITS 
array that has one or two of the axes consisting of a single pixel, 
and an application writer SHOULD consider coding this capability into 
the application. Writers of new applications which generate FITS 
files intended to be described as "image/fits" SHOULD consider using 
the WCSAXES keyword [WCS1] to declare the dimensionality of such 
degenerate axes, so that NAXIS can be used to convey the number of 
non-degenerate axes. 


Magic number(s): "SIMPLE = T 


Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has 
contributed database entries for the magic number file which is used 
by the Unix "file" command. Magic number files with these entries 
are distributed with a variety of Unix-like operating systems. In 
addition to recognizing a FITS file using the string given above, the 
Uphoff entries also recognize the data type of the pixels in the 
PHDU. 


File extension (s): fits 
This file extension SHOULD NOT be interpreted as a prescription. 


The FITS standard originated in the era when files were stored and 
exchanged via magnetic tape; it does not prescribe any nomenclature 
for files on disk. Various sites within the FITS community have 
long-established practices where files are presumed to be FITS by 
context. File extensions used at such sites commonly indicate 
content of the file instead of the data format. 


In the absence of other information it is reasonably safe to presume 
that a file name ending in ".fits" is intended to be a FITS file. 
Nevertheless, there are other commonly used extensions; e.g., ".fit", 
",fts", and many others not suitable for listing in a media type 
registration. 
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Intended usage: Common 
Persons to contact for further information: 


"Steve Allen" <sla@ucolick.org> 
"Don Wells" <dwells@nrao.edu> 


Author/Change controller: 
"Steve Allen" <sla@ucolick.org> 
The IAU FITS Working Group may authorize changes to this document. 
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7. Security Considerations 


The security considerations of interchanging FITS files are discussed 
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